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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the MBMS Synchronisation Protocol. For the release of this specification it is used on 
lu towards UTRAN. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 25.410: "UTRAN lu interface: General Aspects and Principles". 

[3] 3GPP TS 25.323: "Packet Data Convergence Protocol (PDCP) specification". 

[4] 3GPP TS 25.346: "Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the 

Radio Access Network (RAN); Stage 2". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

RAN Access interface: interface between the Core Network and the Radio Access Network. 

RAN Access node: termination point of the RAN Access interface at the Radio Access Network. 

MBMS RAB: denotes the Radio Access data bearer together with the RAN Access Interface data bearer for MBMS 
service user data transmission. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

SYNC MBMS synchronisation protocol 
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3.4 Specification notations 

For the purposes of the present document, the following notations apply: 

Procedure When referring to a procedure in the specification the Procedure Name is written with the first 

letters in each word in upper case characters followed by the word "procedure", e.g. lu Rate 
Control procedure. 

Frame When referring to a control or data frame in the specification, the CONTROL/DATA FRAME 

NAME is written with all letters in upper case characters followed by the words "control/data 
frame", e.g. TIME ALIGNMENT control frame. 

IE When referring to an information element (IE) in the specification the Information Element Name 

is written with the first letters in each word in upper case characters and all letters in Italic font 
followed by the abbreviation "IE", e.g. Frame Number IE. 

Value of an IE When referring to the value of an information element (IE) in the specification the "Value" is 
written as it is specified in subclause 5.6.3 enclosed by quotation marks, e.g. "0" or "255". 

4 General 

4.1 General aspects for the SYNC protocol for UTRAN 
4.1.1 General aspects 

The MBMS Synchronisation protocol (SYNC) is located in the User plane of the Radio Network layer over the lu 
interface: the lu UP protocol layer. 

The SYNC protocol for UTRAN is used to convey user data associated to MBMS Radio Access Bearers. 

One SYNC protocol instance is associated to one MBMS RAB and one MBMS RAB only. If several MBMS RABs are 
established towards one given UE, then these MBMS RABs make use of several SYNC protocol instances. 

SYNC protocol instances exist at lu access point as defined [2] i.e. at CN and UTRAN. 

Whenever an MBMS RAB requires transfer of user data in the lu UP, an lu UP protocol instance exists at each lu 
interface access points. These lu UP protocol instances are established and released together with the associated MBMS 
RAB. 

The following figure illustrates the logical placement of the SYNC protocol layer and the placement of the Data 
Streams sources outside of the Access Stratum. 
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Figure 4.1.1-1 : SYNC protocol layer occurrence in UTRAN overall architecture (User Plane View) 



SYNC protocol version 1 



5.1 



General 



5.1 .1 Applicablity of SYNC protocol version 1 

This version of the specification specifies the SYNC protocol for UTRAN. It is on top of TNL in lu user plane, i.e. 
lu userplane TNL transports SYNC protocol PDUs over the lu interface. 

As a specification convention, within this specification, the interface between the Core Network and the Radio Access 
Network is denoted as the 'RAN Access Interface', the termination point at the Radio Access Network is denoted as 
'RAN Access Node', the termination point at the Core Network is denoted as 'Core Network (CN). Further, 'MBMS 
RAB' denotes the Radio Access data bearer together with the RAN Access Interface data bearer for MBMS service user 
data transmission. 

For the application of the SYNC protocol to UTRAN, the RAN Access Interface is the lu interface, the RAN Access 
Node is the RNC. 

5.1.1 Operation of tine SYNC protocol 

The SYNC protocol layer is present for data streams that originate in the CN and carry additional information within a 
specific userplane-frame. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

5.1 .2 Interfaces of the SYNC protocol layer 

As part of the Access Stratum responsibility, the SYNC protocol layer provides the services and functions that are 
necessary to handle non access stratum data streams for MBMS. The SYNC protocol layer is providing these services to 
the UP upper layers through a Dedicated Service Access Point used for Information Transfer. 

The SYNC protocol layer is using services of the Transport layers in order to transfer user plane PDUs over the RAN 
Access interface. 
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5.2 SYNC protocol layer services 

The following functions are needed to support the SYNC protocol: 
Transfer of user data along with synchronisation information; 
Transfer of synchronisation information without user data. 

5.3 Services Expected from the UP Data Transport layer 

The SYNC protocol layer expects the following services from the Transport Network Layer: 
Transfer of user data. 
no flow control 

5.4 Elementary procedures 

5.4.1 Transfer of User Data for MBMS procedure 



5.4.1.1 



Successful operation 



The purpose of the Transfer of User Data procedure for MBMS is to transfer RAN Access Interface UP frames from the 
RAN Access interface UP protocol layers at CN to the RAN Access interface UP protocol layer at the RAN Access 
Node. One RAN Access interface UP instance is associated to a single MBMS RAB only. 

The Transfer of User Data procedure is invoked whenever user data for that particular RAB needs to be sent across the 
Radio Access interface. 

The NAS Data Streams specific functions make the padding of the payload (if needed) so that the Radio Access 
interface UP frame payload will be an integer number of octets. Then the NAS Data Streams specific functions perform, 
if needed, CRC calculation of the lu frame payload and passes the Radio Access interface UP frame payload down to 
the Frame Handler function. 

The Frame Handler function within the CN retrieves the packet counter and octet counter value from its internal 
memory, formats the frame header and frame payload into the appropriate PDU Type and sends the Radio Access 
interface UP frame PDU to the lower layers for transfer across the Radio Access interface. If the user data is provided 
with compressed IP header, the Radio Access interface UP frame contains PDCP information and the uncompressed IP 
header. 

The Frame Handler function within the CN is also responsible for appropriate setting of the Time Stamp value in order 
to allow all RAN Access nodes to submit the MBMS user data in a synchronised manner. 
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Upon reception of a user data frame, the RAN Access interface UP protocol layer within the RAN Access node checks 
the consistency of the RAN Access interface UP frame as follows: 

The Frame Handler function checks the consistency of the frame header and the consistency of the packet 
counter value. 

Then the RAN Access node utilises the time stamp information to schedule the user data on the radio interface 
on the next TTI. 



RAN Access 
node 



CN 



TRANSFER OF USER DATA 



Figure 5.4.1.1-1. Successful Transfers of User Data. 



5.4.1.2 



Unsuccessful operation 



If the RAN Access interface UP frame carrying the user data is incorrectly formatted or cannot be correctly treated by 
the receiving RAN Access interface UP protocol layer, or if a frame loss is detected due a gap in the sequence of the 
received frame numbers, the RAN Access node shall cease to provide user data to the radio interface protocol entities 
and wait until the next synchronisation sequence if soft combining and MBSFN are used, or until the next scheduling 
transmission interval if the MRNC and TDM multiplexing are used. 

5.4.2 Transfer of Synchronisation Information for MBMS procedure 
(without user data) 



5.4.2.1 



Successful operation 



The purpose of the Transfer of Synchronisation Information for MBMS procedure is to transfer synchronisation 
information from the CN to the RAN Access node at the end of each synchronization sequence (see [4]) to improve the 
RAN Access node resynchronization in case of packet loss. 

The Frame Handler function within the CN retrieves the synchronisation time stamp from its internal clock and the total 
packet counter and total octet counter from its internal memory, formats the frame header and frame payload into the 
appropriate PDU Type and sends the RAN Access interface UP frame PDU to the lower layers for transfer across the 
RAN Access interface. 

Upon reception of a user data frame, the RAN Access interface UP protocol layer checks the consistency of the RAN 
Access interface UP frame as follows: 

The Frame Handler function checks the consistency of the frame header and the consistency of the 
synchronisation time stamp, total packet counter and total octet counter. 



£75/ 



3GPP TS 25.446 version 8.2.0 Release 8 



11 



ETSI TS 125 446 V8.2.0 (2010-04) 



RAN Access 
node 




CN 




TRANSFER OF SYNC INFO 






^ 


■ 















5.4.2.2 



Figure 5.4.2.1-1. Successful Transfers of Synchronisation Information. 



Unsuccessful operation 



If the RAN Access interface UP frame without user data is incorrectly formatted or cannot be correctly treated by the 
receiving RAN Access interface UP protocol layer, the RAN Access interface UP protocol layer shall either discard the 
frame or pass it to the upper layers with a frame classification indicating a corrupted frame. 

5.5 Elements for the SYNC protocol 
5.5.1 General 

In the present document the structure of frames will be specified by using figures similar to Figure 5.5.1-1. 
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Figure 5.5.1-1. Example frame format. 

Unless otherwise indicated, fields which consist of multiple bits within an octet will have the more significant bit 
located at the higher bit position (indicated above frame in Figure 5.5.1-1). In addition, if a field spans several octets, 
more significant bits will be located in lower numbered octets (right of frame in Figure 5.5.1-1). 

On the lu interface, the frame will be transmitted starting from the lowest numbered octet. Within each octet, the bits 
are sent according decreasing bit position (bit position 7 first). 

Spare bits should be set to "0" by the sender and should not be checked by the receiver. 
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The header part of the frame is always an integer number of octets. The payload part is octet rounded (by adding 
'Padding' when needed). 

The receiver should be able to remove an additional spare extension field that may be present at the end of a frame. See 
description of Spare extension field. 

5.5.2 Frame format for the SYNC protocol 



5.5.2.1 



Transfer of Synchronisation Information without payload (SYNC PDU Type 0) 



This Frame Format is defined to transfer synchronisation information over the RAN Access Interface UP without user 
data payload. 

The following shows the SYNC frame structure for PDU TYPE data frame of the RAN Access Interface UP protocol 
at the SAP towards the transport layers (TNL-SAP). 
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Figure 5.5.2.1-1. SYNC PDU Type Format. 

The SYNC PDU TYPE data frame is made of two parts: 

1) SYNC Frame Control part (fixed size); 

2) SYNC Frame Check Sum part (fixed size); 

5.5.2.2 Transfer of User Data for MBMS with uncompressed header (SYNC PDU 

Type1) 

This Frame Format is defined to transfer user data over the RAN Access Interface UP for user data with uncompressed 
header. 

The following shows the SYNC frame structure for PDU TYPE 1 data frame of the RAN Access Interface UP protocol 
at the SAP towards the transport layers (TNL-SAP). 
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Figure 5.5.2.2-1. SYNC PDU Type 1 Format. 

The SYNC PDU TYPE 1 data frame is made of three parts: 

1) SYNC Frame Control part (fixed size); 

2) SYNC Frame Check Sum part (fixed size); 

3) SYNC Frame Payload part (SDU sizes rounded up to octets [Note: this does not consider the usage of spare 
extension field]). 

5.5.2.3 Transfer of User Data for MBMS with compressed header (SYNC PDU Type 

2) 

This Frame Format is defined to transfer user data over the RAN Access Interface UP for user data with compressed 
header. 

The following shows the SYNC frame structure for PDU TYPE 2 data frame of the RAN Access Interface UP protocol 
at the SAP towards the transport layers (TNL-SAP). 
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Figure 5.5.2.3-1. SYNC PDU Type 2 Format. 

The SYNC PDU TYPE 2 data frame is made of three parts: 

1) SYNC Frame Control part (fixed size); 

2) SYNC Frame Check Sum part (fixed size); 

3) SYNC Frame Payload part (SDU sizes rounded up to octets [Note: this does not consider the usage of spare 
extension field]). 

5.5.3 Coding of information elements in frames 



5.5.3.1 



PDU Type 



Description: The PDU type indicates the structure of the SYNC frame. The field takes the value of the PDU Type it 
identifies: i.e. "0" for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame. 

Value range: {O=synchronisation frame without payload, l=user data with synchronisation frame for uncompressed 
headers, 2=user data with synchronisation frame for compressed headers, 3-15=reserved for future PDU type} 
extensions } 



Field length: 4 bits 



5.5.3.2 



Timestamp 



Description: Relative time value for the starting time of a synchronization sequence within the synchronisation period. 
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Value range: {0... 60000-1 } Unit: multiples of 10ms. 

Note: The value range allows for a synchronisation period of 600s. 

Field length: 2 octets 

5.5.3.3 Packet Number 

Description: This parameter indicates the number of elapsed SYNC PDUs cumulatively within the synchronization 
sequence. It helps the RAN Access node to notice the loss of SYNC PDUs. Additionally it is used to reorder the PDUs 
in the RAN Access node. The Packet number is reset at the end of every synchronisation sequence. SYNC PDUs of 
Type are not counted by this parameter. 

Value range: {0..2"'-l}. 

Field length: 2 octets. 

5.5.3.4 Elapsed Octet Counter 

Description: This parameter indicates the number of elapsed cumulative octets cumulatively within one 
synchronisation sequence. It helps the RAN Access node to know how many packets were not received in case of 
packet loss. This counter is reset at the end of every synchronisation sequence. Octets of SYNC PDUs of Type are not 
counted by this parameter. 

Value range: {0..2^^-l}. 

Field length: 4 octets. 

5.5.3.5 Total Number Of Packet 

Description: This parameter indicates cumulatively the number of the packets for the MBMS service within one 
synchronization period. SYNC PDUs of Type are not counted by this parameter. 

Value range: {0..2^*-l}. 

Note: In case of soft combining and MBSFN(except for case MRNC is used and TDM multiplexing is used), the 
parameter shall be ignored in RNC. 

Field length: 3 octets. 

5.5.3.6 Total Number Of Octet 

Description: This parameter indicates cumulatively the number of the octets for the MBMS service within one 
synchronization period. Octets of SYNC PDUs of Type are not counted by this parameter. 

Value range: {0..2*-l}. 

Note: In case of soft combining and MBSFN(except for case MRNC is used and TDM multiplexing is used), the 
parameter shall be ignored in RNC. 

Field length: 5 octets. 

5.5.3.7 PDCP Information 

Description: This parameter contains PDCP Information as specified in [3]. 
Value range: as specified in [3]. 
Field length: 1 octet. 

5.5.3.8 IPv6 Indicator 

Description: This parameter indicates whether the Uncompressed Payload IP header is of IPv6 type. 
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Value range: {0=IPv4, l=IPv6}. 
Field length: 1 bit. 

5.5.3.9 Uncompressed Payload IP header 

Description: This parameter provides the uncompressed IP header of the payload. 

Value range: {any value} 

Field length: 20 bytes if IPv6 lndicator=0, 40 bytes if IPv6 Indicator=l. 

5.5.3.10 Header CRC 

Description: This field contains the CRC of all fields in Frame Control Part. The CRC is a 6-bit checksum based on the 
generator polynom G(D) = D''+D^+D^+D^+D'+1, see subclause 5.6.2. With this CRC all error bursts shorter than 7 bits 
are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 24 bits, 
(max 3 octets). 

Field length: 6 bits. 

5.5.3.11 Payload CRC 

Description: This field contains the CRC of all the fields (including Padding and possible Spare extension) of the 
Frame Payload Part. The CRC is a 10 bit checksum based on the generator polynom G(D) = D'^h- DVD^h-D'*h-D'h-1, see 
subclause 5.6.2. With this CRC all error bursts shorter than 1 1 bits are detected, as well as all odd number of bits faulty 
(and two-bit faults) when the protected area is shorter than 500 bits (max 62 octets). 

Field length: 10 bits. 

5.5.3.12 Padding 

Description: This field is an additional field used to make the frame header or payload part an integer number of octets 
when needed. Padding is set to "0" by the sender and is not interpreted by the receiver. 

Value range: {0-127}. 

Field length: 0-7 bits. 

5.5.3.13 Spare 

Description: The spare field is set to "0" by the sender and should not be interpreted by the receiver. This field is 
reserved for later versions. 

Value range: (0-2"-l). 

Field Length: n bits. 

5.5.3.14 Spare extension 

Description: The spare extension field is reserved for extension in later versions. It shall not be sent. The receiver 
should be capable of receiving a spare extension. The spare extension should not be interpreted by the receiversince in 
later versions of the present document additional new fields might be added in place of the spare extension. The spare 
extension can be an integer number of octets carrying new fields or additional information; the maximum length of the 
spare extension field (m) depends on the PDU type. 

Value range: 0-2'"***-l. 

Field Length: 0-m octets. For PDU Types in the set {0,1 }, m=4. For PDU Types in the set {14}, m=32. 
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5.5.3.15 Payload fields 

Description: This field contains the payload of the MBMS user data. 

Value range: {any value}. 

Field length: Sum of the lengths of the included Subflow SDUs. 

5.5.4 Timers 

not applicable 

5.6 Handling of unknown, unforeseen and erroneous protocol 
data 

5.6.1 General 

void 

5.6.2 CRC Calculation 

The parity bits are generated by one of the following cyclic generator polynomials: 
gcRC6(D) = D" + D' + DV D' + D' + 1; 

gcRcio(D) = D'" + D" + D^ + D^ + D' + 1. 

Denote the bits to be protected of a frame by (5[j , flj ? '^3 ? ■ • • ? '^ a ^ ^1 being the bit with the highest bit position in the 
first octet), and the parity bits by p^, P2, p^,- ■■, Pi ■ Aj is the length of the protected data and L, is 6 or 10 depending 
on the CRC length. 

The encoding is performed in a systematic form, which means that in GF(2), the polynomial 
a^D^'^' +a2D^'^' +... + a^p'' + p^D' + p^D" +...+ p^D' + p^ 
yields a remainder equal to when divided by gcRC6(D) and the polynomial 
ajZ) ' +a2£> +... + a^D + p^D + P2D +...+ pgD + p,o 

yields a remainder equal to when divided by gcRcio(D). If A, = , Pi — P2 — P3 —'" — Pl ~ ^ ■ 

5.6.3 Relation between input and output of the Cyclic Redundancy Check 

The protected bits are left unchanged in the frame. The parity bits for the Header CRC are put in the Header CRC field 
with Pj being the highest bit position of the first octet of the Header CRC field. The parity bits for the Payload CRC 
are put in the Payload CRC field with p^ being the highest bit position of the first octet of the Payload CRC field. 



£75/ 



3GPP TS 25.446 version 8.2.0 Release 8 



18 



ETSI TS 125 446 V8.2.0 (2010-04) 



Annex A (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


1 2/2008 


42 


RP-080831 






Presented to TSG-RAN for approaval 




1.0.0 


1 2/2008 


42 


RP-080831 






approved at TSG-RAN#42 and placed under change control 


1.0.0 


8.0.0 


1 2/2009 


46 


RP-091182 


0002 


1 


Ignorance of Total Number Of Packet and Total Number Of 
Octet in case of Soft Combining and MBSFN 


8.0.0 


8.1.0 


1 2/2009 


46 


RP-091182 


0003 


2 


Correction for SYNC Protocol 


8.0.0 


8.1.0 


03/201 


47 


RP-100219 


0009 


1 


Corrections on Packet Number 


8.1.0 


8.2.0 



































£75/ 



3GPP TS 25.446 version 8.2.0 Release 8 



19 



ETSI TS 125 446 V8.2.0 (2010-04) 



History 



Document history 


V8.0.0 


January 2009 


Publication 


V8.1.0 


January 2010 


Publication 


V8.2.0 


April 2010 


Publication 















£75/ 



